\section{Descripción de la arquitectura}

A continuación haremos una presentación de la arquitectura completa propuesta. Para esto nos basaremos fuertemente
en una vista de componentes y conectores para detallar las interacciones en runtime de los componentes del sistema.

En la figura ~\ref{fig:arquitectura} se puede encontrar el diagrama de arquitectura general. Utilizamos una notación
similar a la estándar de la cátedra, con una pequeña extensión: un componente que goza de las mismas cualidades que el
clásico Client/Server, pero que además agrega encripción al canal de transmisión. A continuación se puede encontrar una
referencia de los conectores utilizados:
\\\\
\begin{figure}[hbtp]
	\centering
	\includegraphics[scale=0.45]{./graficos/referencias.jpg}
	\caption{Notación utilizada para la vista de componentes y conectores.}
	\label{fig:referencias}
\end{figure}
\\

Dentro del recuadro se encuentran los componentes que forman parte de la infraestructura manejada por el equipo. Fuera
del mismo se encuentran servicios externos y otros componentes que interactuan con las interfaces que provee nuestro
sistema.

A grandes rasgos, vemos que hay una aplicación web que hace de \textit{frontend} al sistema. Detrás de esta hay una
secuencia de componentes encargados de realizar el procesamiento de un comentario. El esquema de procesamiento está
inspirado levemente en un estilo \textit{pipe and filter}, pero con alguna modificación para permitir concurrencia en el
procesamiento de imágenes y audio (detalles más adelante).

Para garantizar los requerimientos de disponibilidad, se introdujo un componente encargado de llevar registro de en qué
etapa del procesamiento se encuentra cada comentario. A su vez, otro componente registra todos los eventos del
procesamiento de comentarios para consultas de auditoría. Ambos son notificados de estos eventos a través de un
\textit{publisher/subscribe bus}, en el cuál los componentes del pipe publican la información relevante.

Por otra parte, los datos de comentarios sin procesar se exponen a través de un \textit{API} al servicio de data-mining
para análisis de tendencias.

En los siguientes apartados se describe en mayor detalle el comportamiento de cada componente. 

\begin{figure}[hbtp]
	\centering
	\includegraphics[scale=0.4]{./graficos/arquitectura.jpg}
	\caption{Diagrama de arquitectura del sistema.}
	\label{fig:arquitectura}
\end{figure}


\subsection{Aplicación web}

Desde el punto de vista del usuario, el punto de entrada al sistema es la aplicación web del Gobierno de la Ciudad. Esta
aplicación tiene acceso a un repositorio donde se encuentra la información de perfil y preferencias de cada usuario. En
caso de ser un usuario autenticado a través de alguna red social, la aplicación web se comunica con el \textit{API}
correspondiente. Nótese que toda comunicación que involucre un pasaje de credenciales del usuario hacia o desde fuera
del sistema se realiza mediante un canal encriptado para preservar la confidencialidad de los datos del usuario.
En caso de que un usuario publique un comentario, la aplicación web publica el evento en el bus, lo cual hace que se
registre para auditoría y se guarde el comentario en estado \textit{pendiente de análisis}.


\subsection{Pipe de procesamiento}

Tras recibir el pedido de publicación, la aplicación web envía el comentario a un pipe de procesamiento. Por cuestiones
de auditoría (y en caso de que hiciera falta retomar el procesamiento por caída de algún componente), se registra el
resultado al final de cada etapa. Se describe a continuación el comportamiento de cada paso.


\subsubsection{Aumentador de mensajes}

Además del contenido de un mensaje y sus adjuntos multimedia, hace falta evaluar y clasificar los enlaces del mismo. Es
por esto que el primer filtro se encarga de buscar dichos enlaces, adquirir de Internet el contenido de los mismos y
adjuntarlo al mensaje original. Por ejemplo, si un comentario incluye un link a una fotografía pornográfica, este
componente la descargará y la agregará al mensaje como si hubiese sido una imagen adjunta del mismo.

Nótese que en el diagrama figuran potencialmente varios de estos componentes. La razón de esto es que traer contenido de
Internet puede ser lento, y se identificó en este componente un potencial cuello de botella. Para que esto no impacte en
la performance general, de buscó que fuera fácil agregar nuevos aumentadores, con el objetivo de aumentar la
concurrencia y evitar que se encolen mensajes en esta etapa.

\subsubsection{Splitter y agregador de resultados}

Tras enriquecer el comentario original con el contenido de los enlaces, ya se está en condiciones de iniciar la
clasificación de los adjuntos de un comentario. Hay tres tipos de adjuntos permitidos al momento: audio, imágenes y
video.

La estrategia de análisis consiste en obtener una descripción en texto del contenido de los aduntos, utilizando
los servicios de análisis de audio e imágenes provisto por los grupos de investigación locales. Una vez hecho esto,
se utilizará nuestro algoritmo de avanzada para clasificar tanto el comentario como sus adjuntos.

\begin{figure}[hbtp]
	\centering
	\includegraphics[scale=0.45]{./graficos/agregador.jpg}
	\caption{Paralelización del procesamiento de imágenes y audio.}
	\label{fig:agregador}
\end{figure}

Para analizar video, se cuenta con un componente (aquí llamado \textit{splitter}) que de encarga de samplear el video
y obtener un reducido número de frames significativos, los cuáles serán analizados como cualquier otra imagen. En el caso
de tratarse de video 3D, aplica una transformación para unificar las capas de color rojo y verde del anaglifo. A su vez,
extrae la pista de audio para ser analizada también por su cuenta.

Tras pasar por el splitter, se descompone el comentario en una serie de imágenes, clips de audio y texto, y se envía
entonces a clasificar el contenido multimedia al componente correspondiente. Recién en el momento que se clasificaron
por completo todos los adjuntos de un comentario se sigue adelante. Esto se logra utilizando un componente que agrupa
todos los resultados parciales de procesamiento, aquí llamado \textit{agregador de resultados}. Aparte de la imagen o
audio a analizar, cada mensaje contiene el identificador del comentario original y la cantidad de adjuntos totales.

En el momento que el agregador detecta tener el resultado de clasificación de todos los adjuntos de un mismo comentario
envía resultado a las siguientes etapas. También se publica en el bus un evento para que se persista el resultado de
esta etapa de procesamiento y se guarden los logs de auditoría correspondientes. En la figura ~\ref{fig:agregador} se
puede ver un ejemplo de cómo funciona este componente.


\subsubsection{Módulos de categorización de imágenes y audio}

La descripción en formato texto de los adjuntos en audio e imagen se obtienen utilizando los servicios externos
provistos por los grupos de investigación. Nuestro sistema cuenta con componentes especiales para contactarse
con estos servicios. Por un lado implementan el protocolo definido con los proveedores, y a su vez cuentan con la
lógica necesaria para reintentar en caso de que se haya fallado alguno de los pedidos.

Se puso de acuerdo un protocolo por el cuál nuestro sistema envía un mensaje asincrónico con el adjunto a procesar.
Cuando el procesamiento termina, el servicio externo envía a nuestros componentes otro mensaje asincrónico con el
resultado del procesamiento. Esto posibilita una lógica similar a la de un conector \textit{call/return} pero sin
necesidad de bloquear los puertos de nuestro componente mientras se procesa un pedido.

El grupo de investigación se comprometió a cumplir con los requerimientos de performance detallados en los escenarios de
atributos de calidad, por lo cuál garantizan un máximo de tiempo de procesamiento por cada kilobyte de datos. Con esto
en cuenta, nuestros componentes guardan el tiempo en que se realizó cada pedido, y en caso de sobrepasarse el tiempo
límite se asume que falló el procesamiento remoto y se reintenta.


\subsubsection{Analizador de virus}

De forma similar a como ocurre con el procesamiento de imágenes y audio, la interacción con el sistema de detección de
malware y virus se realiza a través de un par de llamador asincrónicos, realizando reintentos en caso de no recibir una
respuesta en tiempo y forma.

En caso de detectarse alguna anomalía en el mensaje, éste se filtra y no pasa a la etapa de análisis de texto. Por
otra parte, los resultados de esta etapa también se publican en el bus para registrar el estado del comentario y
actualizar los registros de auditoría.


\subsubsection{Analizador de texto}

Terminada la detección de virus y malware, ya se cuenta todo el contenido del comentario en formato texto listo para ser
analizado por nuestro algoritmo propio. Éste se encarga de clasificar el comentario según las distintas categorías
definidas (insultos, pornografía, referencias a ponys, etc.). Esta etapa es la más exigente en cuanto a procesamiento,
por la complejidad del anális de las distintas categorías.

Aparte de esto, en el futuro podrían agregarse nuevas categorías que lo hagan todavía más costoso. Es por esto que se
definieron componentes separados por cada tipo de análisis. Al recibir un comentario, se analiza concurrentemente el
mismo en busca de todas las categorías presentes hasta el momento. En caso de ser necesario, podría incluso haber varios
componentes dedicados al análisis de cada categoría. De esta forma, es posible replicar dichos componentes a medida que
el tráfico vaya creciendo para mantener las garantías de performance.

Al finalizar el análisis de cada categoría, los resultados se publican en el bus al igual que en las etapas anteriores.
Hecho esto, el comentario ya está listo para ser mostrado a los usuarios, dependiento del filtro que tengan configurado
para cada categoría. En la figura ~\ref{fig:deteccion_texto} se puede ver en detalle la composición del componente de
análisis de texto.
\\\\

\begin{figure}[hbtp]
	\centering
	\includegraphics[scale=0.6]{./graficos/deteccion_texto.jpg}
	\caption{Clasificación del contenido de los comentarios.}
	\label{fig:deteccion_texto}
\end{figure}


\subsection{Módulo de seguimiento del procesamiento de comentarios}

Como se explicó previamente, cada etapa del pipe de procesamiento publica su resultado en el bus. Uno de los componentes
suscritos a los eventos de dicho bus es el \textit{módulo de seguimiento del procesamiento de comentarios}. Tiene acceso
a un repositorio (base de datos) donde persiste el estado de procesamiento de cada elemento. En base a los eventos que
lee, toma las siguientes acciones:

\begin{itemize}
	\item Cuando llega un nuevo comentario a procesar, lo guarda en estado {pendiente de análisis}
	\item Tras la conversión a texto de todos los contenidos adjuntos y de los enlaces, se guardan los resultados y se actualiza el estado del comentario en el repositorio.
	\item Tras el análisis de virus/malware, marca los comentarios como \textit{limpios} o \textit{inseguros}.
	\item Guarda los resultados de análisis de comentarios por cada categoría analizada, para luego permitir filtrarlos
	según la preferencia de cada usuario.
\end{itemize}

Nótese que cada notificación sirve de \textit{checkpoint}. En caso de falla de algún componente se cuenta con toda la
información necesaria para continuar con el procesamiento.


\subsection{Módulo de auditoría}

El otro suscriptor del bus de eventos es el \textit{módulo de auditoría}, que guarda registro de todos los comentarios
ingresados, así como su estado y resultados parciales de cada etapa del procesamiento. Provee, a su vez, una sencilla
interfaz para consultar todos los eventos registrados hasta el momento a personas con autorización.


\subsection{API de acceso a comentarios}

Se provee un API de acceso a los comentarios sin filtrar, para que la compañía de datamining pueda llevar a cabo su
proceso de análisis de tendencias. Dado que no se desea exponer la base de datos de comentarios entera a cualquier
individuo, se utiliza autenticación (via un token generado especialmente para la compañía) y también se encripta el
canal de transmisión.